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(54) Framework for business applications providing financial integration 



(57) The present invention relates to a method of 
developing a software system using Object Oriented 
Technology and frameworks for developing a business 
application. 

The present invention solves this problem with a 
framework framework comprising a using non-financial 
component integration base class, a target financial 
component integration base class, and a generic data 
conversion engine. 

The present invention is applicable in the techniclal 
field of application development of software systems, 
e.g. for a business application as Financial or Logistic 
and Distribution, wherein it is the purpose of frame- 
works to provide significant portions of the application 
that are common across multiple implementations of the 
application in a genera! manner, easy to extend for spe- 
cific implementation. 
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Description 

Field of the Invention 

[00011 The present Invention relates to a method of 
developing a software system using Object Oriented 
Technology and frameworks for developing a business 
application. 

[0002] The present application relates to the following 
co-pending applications filed by the same applicant with 
the same filing date: 

"A method of developing a software system using 
Object Oriented Technology" (Applicant's docket 
No. GE 997 034) 

"A method for using decoupled chain of responsibil- 
ity" (Applicant's docket No. GE 997 035) 
"Framework for business applications using cached 
aggregate and specification key (Applicants docket 
No. GE 997 039) 

"Software business objects in a multi-level organi- 
zational structure" (Applicant's docket No. GE 997 
040) 

"Method of error handling in a framework" (Appli- 
cant's docket No GE 997 041) 
"A method of locating software objects in different 
containers" ((Applicant's docket No. GE 997 042) 

Descriotion of the Prior Art 

[0003] In order to maintain or enlarge their competi- 
tiveness, enterprises of almost every type of business 
all over the world have to rework and bring up to date 
their information technology to meet customer's require- 
ments and thus to be successful in the market. But 
keeping an information system based on traditionally 
developed software up to date is at least an expensive 
undertaking, and in many cases it is an unsolvable 
problem. Object Oriented Technology or simply Object 
Technology, often abbreviated "OOT" or simply "OT", 
has the technical potential to overcome the problems 
associated with development, maintenance, and exten- 
sion of software applications within a company's infor- 
mation system and to provide interoperability and 
adaptability across multiple applications and hardware 
platforms. 

[0004] Object Oriented Technology describes a 
method for the development of operating software as 
well as application software for a computer system. 
Contrary to the traditional, non object oriented ways of 
developing software, Object Oriented Technology com- 
prises and uses preengineered "methods" and "objects" 
for the development of software, comparable to tools 
and parts for the development of an automobile. 
[0005] Similar to the development of an automobile, 
wherein not each required screw is developed individu- 
ally, but standardized screws are used which can be 
individually adapted by shortening to the required 



length, within the development of software, Object Ori- 
ented Technology provides a "dass" as a kind of soft- 
ware template from which individual "objects" can be 
instantiated. These classes are usually stored in a soft- 

5 ware library or a so called "class library". A class library 
is simply a collection of several classes stored together 
in a special filing format called a library. 
[0006] In Object Oriented Technology an "object" is a 
self-contained piece of software consisting of related 

10 data and procedures. Data means information or space 
in a computer program where information can be 
stored. e.g. a name or an inventory part number. Proce- 
dures are parts of a program that cause the computer to 
actually do something, e.g. the parts of a program which 

15 perform calculations or the part of a program that stores 
something on a computer disk. In Object Oriented Tech- 
nology, an object's procedures are called "methods". 
[0007] The concept of an object being a self-contained 
piece of software having data and procedures inside 

20 itself is a new way of developing software. In non object 
oriented software, most of the data for an entire pro- 
gram is often grouped together near the beginnir>g of 
the program, and the procedures then follow this com- 
mon pool of data. This conventional method worked 

25 okay for smaller programs, but as soon as a piece of 
software started to grow and become somewhat com- 
plex, it become increasingly difficult to figure out which 
procedures were using which data. This made it quite 
difficult and expensive to debug or change traditional 

30 software programs. 

[0008] In Object Oriented Technology it is generally 
easier to debug, maintain, and enhance object oriented 
software. The most popular object oriented program- 
ming languages are probably "C++", "JAVA", and 

35 "Smalltalk". The concept that both data and methods 
are contained inside an object is called "encapsulation". 
Part of the concept of encapsulation is that an object 
has a predictable way of communicating with other 
objects, a so called predictable "interface" or sometimes 

40 also called the method contract. 

[0009] Provided that interface will not be changed, the 
code or methods inside the object can be changed with- 
out disrupting other objects' ability to interact with that 
object. For example, a TAX CALCUI-ATION object 

45 would have a predictable interface for use by PAY- 
CHECK objects. Provided that interface will not be 
changed, the detailed program code inside the TAX 
CALCULATION object could be changed whenever the 
tax laws changed, and no other objects in the payroll 

50 system would have to know anything about such 
changes. 

[001 0] In Object Oriented Technology the term "inher- 
itance" is used to communicate the concept that one 
object can inherit part of its behavior and data from 
55 another object, e.g. since an employee is a type of per- 
son, an EMPLOYEE object might inherit the character- 
istics of a PERSON object, such as having name, birth 
date, and address data, as well as an EMPLOYEE 
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object might inherit methods for updating and displaying 
these data. 

[001 1 ] Even if an object inherits some of its character- 
istics from other objects, that object can, and usually 
would, also have its own non-inherited characteristics, s 
e.g. whereas a PERSON object would have an inherita- 
ble method to display a person's address, a PERSON 
object would probably not have a method for displaying 
paycheck history, since not all persons get paychecks. 
Because an EMPLOYEE object could not inherit this io 
method from a PERSON object, an EMPLOYEE object 
would have to define its own method for displaying pay- 
check history. 

[0012] Although Object Oriented Technology clearly 
seems to be the most sophisticated way for the develop- 75 
ment, mainentance, and extension of software applica- 
tions, many companies developing software 
applications are concerned about the cost and risks 
involved with the rework of existing applications and 
with the construction of new applications using Object 20 
Oriented Technology For those software application 
developers, a technical foundation for software applica- 
tions has to be built as a tool using Object Oriented 
Technology as the basis, allowing each developer to 
develop highly unique software products. This technical 25 
foundation is formed by frameworks comprising the 
basic application structure which software application 
developers previously had to develop by themselves. 
[001 3] In Object Oriented Technology the term "frame- 
work" is used to describe a reusable set or collection of 30 
classes which work together to provide a commonly 
needed piece of functionality not provided by any of the 
individual classes inside the framework. Thus a frame- 
work defines a specific way in which multiple objects 
can be used together to perform one or more tasks 35 
which no single object performs. In other words, a 
framework is a reusable, predefined and preengineered 
bundle of several objects which address a recurring pro- 
gramming problem. 

[001 4] Frameworks provide a way of capturing a reus- 40 
able relationship between objects, so that those objects 
do not have to be reassembled in that same relationship 
every time they are needed. Frameworks provide a way 
of grouping multiple objects together to perform some 
function which should not have to be thought through 45 
each time at the underlying object level. For example, a 
PRINT framework would consist of all the objects nec- 
essary for a programmer to easily print something on 
any printer, and would probably include objects for 
printer selection, spooling to disk or error detection as so 
"out of paper". Frameworks can be regarded as a group 
of software objects which contain a technical foundation 
for a software application. For example in the business 
field of Financial, Logistic and Distribution or Produc- 
tion. Although a framework represents a skeleton of a ss 
software application, usually a framework is not an exe- 
cutable software program. 

[001 5] E. GAMMA et al: "Design Patterns: elements of 



reusable object-oriented software", Addison-Wesley, 
1995, ISBN 0-201-63361-2, gives a useful introduction 
to Object Oriented Technology in general and to design 
pattern more specifically, in particular with regard to the 
present invention. 

[001 6] By providing frameworks as the technical foun- 
dation for developing software applications, the follow- 
ing problems have to be addressed: 
[001 7] Applications have to support all hardware plat- 
forms and related software operating systems relevant 
on the market. Applications have to fulfill the require- 
ments related to client/server corrfigurations including 
the requirement for graphical user interfaces and win- 
dowing techniques. Also, applications have to offer 
internet compatibility and access on demand. Further- 
more applications have to provide integrated solutions 
with respect to installed software. 
[001 8] In particular, the core of most business applica- 
tions is the General Ledger. One of the more difficult 
problems that must be solved by a business application 
is how to enable multiple diverse business application 
components, e.g., payroll/personnel, warehouse man- 
agement, manufacturing, in many cases developed by 
different development organizations, to provide input to 
the General Ledger in a manner which is tailored to 
each component's specific requirements. This task 
must be accomplished while at the same time enabling 
multiple General Ledger components, again developed 
by different development organizations, to interoperate 
with the framework. The framework must also support 
applications that choose not to provide a General 
Ledger component without requiring the remaining 
application components to be modified in any way. 
[0019] In addition, frameworks must be capable of 
supporting flexible representations of a set of non-uni- 
form items. 

[0020] Within the accompanying figures, representa- 
tion standards for classes, objects, relationships etc. are 
used at least partly according to Grady Booch: "Object- 
Oriented Analysis and Design with Applications", sec- 
ond edition, The Benjamin/Cummings Publishing Com- 
pany, Ind., Redwood City, CA, USA. 

Obiect of the Invention 

[0021] It is an object of the present invention to pro- 
vide a technical foundation for tiie development of soft- 
ware applications using Object Oriented Technology 
which overcomes the above discussed problems. 
[0022] It is a further object of the present invention to 
enable multiple diverse business application compo- 
nents to provide input to the General Ledger component 
in a manner which is tailored to each component's spe- 
cific requirements. 

Summary of the Invention 

[0023] TTie present invention solves this object with 
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methods and apparatus as laid down in enclosed inde- 
pendent claims. Particular embodiments of the present 
invention are presented in the respective dependent 
claims. 

[0024] In particular, the present invention provides a 5 
framework to be used for developing a software system, 
e.g. for a business application, said framework is a 
financial integration framework characterised in that 
said financial integration framework is composed of 
three major components: Using non-financial compo- io 
nent integration base classes, target financial or Gen- 
eral Ledger component integration base classes, and a 
generic data conversion engine. 
[0025] This invention is easily customizable to any 
specific business application component. Furthermore, is 
it enables cross-component data mapping at any level 
of complexity desired by the development organization, 
providing a generic data conversion engine whose 
mechanism is fully functional without development 
organization modification. This engine accepts the 20 
diverse data provided by the other components of the 
framework in the form of domain-specific class 
instances, such as Product, Warehouse, Customer, and 
Stock Type for a warehouse management component 
and converts that data into a form compatible with the 25 
General Ledger framework interface, i.e. Generic Dis- 
sections containing Generic Posting Combinations 
made up of one or more instances of Generic Analysis 
Codes, each of which is associated with a separate 
Generic Analysis Group. It operates independently of 30 
any General Ledger application component at a basic 
level, while enabling any General Ledger application 
component developed for the framework to easily 
replace the basic level function with its own more 
sophisticated function. 35 

Brief Description of the Drawings 

[0026] 

40 

Figure 1 shows a four layer schema from which soft- 
ware application can be developed using 
the present invention. 

Figure 2 shows the three main sections comprised 45 
by the financial integration framework. 

Figure 3 shows specialized and default mappings. 

Figure 4 shows the generic journal building process, so 

Figures shows an example of mapping for one 
Analysis Group for a particular Generic 
Dissection Type. 

55 

Figure 6 shows a more complex example with two 
Generic Dissection types, three Analysis 
Groups, and three Account Control types. 



Figure 7 shows an example of using the maps 
defined in Figure 6. 

Detailed Description 

[0027] Developing software applications using the 
subject of the present invention as a development tool 
can be regarded as built up of four layers as shown in 
Figure 1 . 

[0028] The lowest layer is the base layer 101. The 
base layer 101 provides and manages the interface with 
the server hardware 1 1 1 which is potentially running 
under different operation systems such as OS/2, 
OS/400, A IX, and NT. The server hardware 1 1 1 is con- 
nected with client hardware 112 via a communication 
network 1 13. The client hardware 112 may also poten- 
tially running under different operation systems such as 
OS/2, NT, and AIX. The embodiment shown in Figure 1 
shows the development of the server portion of a cli- 
ent/server application only. 

[0029] The Base layer 101 represents the technical 
foundation for the higher level objects including many 
functions near to an operating system such as finding 
objects, keeping track of their names, controlling access 
to them, resolving conflicts, security administration, and 
installation. The Base layer 101 also includes the so 
called Object Model Classes which provide a consistent 
nKxiel for building objects while hiding the complexity of 
tiie underlying infrastructure form the software applica- 
tion developer. The Base layer 101 can be regarded as 
a kind of lower middleware necessary for the application 
of the Object Technology above it using the interface 
functionality provided by the Base layer 101. 
[0030] Above the Base layer 101 there is a layer com- 
prising Common Business Objects 102. This Common 
Business Object layer 102 provides a large number of 
objects which perform functions commonly needed 
within a business application, e.g. date and time, cur- 
rency, address, units of measure, and calendar. These 
Common Business Objects represent the building 
blocks from which software application developers can 
select and create business applications, e.g. these 
Common Business Objects can be copied and 
extended to perform new functions as for example the 
date and time object can be extended to handle the Chi- 
nese calendar. 

[0031] The layer 103 above the Common Business 
Objects layer 102 already comprises Core Business 
Processes and can be regarded as the Core Business 
Process layer 103. Although layer 103 usually does not 
provide executable code, within this layer 103 the busi- 
ness software applications developed using the present 
invention begin to take shape. Each Core Business 
Process layer is built for one specific type of application, 
as for example General Ledger or Warehouse Manage- 
ment. 

[0032] This Core Business Process layer 103 can be 
regarded as an upper middleware which - although not 
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a complete software application program - already con- 
tains the basic funtions which all of the application pro- 
grams of this type require. It is the Core Business 
Process layer 103 which creates the application frame- 
works, wherein some of the Common Business Objects 
are linked to a large number of objects specific to the 
type of framework being built, e.g. Warehouse Manage- 
ment. The resulting framework is constructed in a way 
to contain commonly used functions as well as to be 
easy to extend. 

[0033] On top of the above described three layer 
model the application software is located, created by 
the software application developer and representing 
executable code. It is the choice of a software applica- 
tion developer whether to use only the base layer 101, 
the base layer 101 and the Common Business Object 
layer 102, or ail three layers 101, 102, and 103 for the 
development of his software application. In every case 
he has to develop a remaining part of the application by 
himself and therefore every resulting software applica- 
tion program will be a completely unique product. 
[0034] It has to be noted that the subject of the present 
invention is represented within the three layer model 
101 , 102, and 103 and is not represented by the execut- 
able code of the software application 121 developed 
using the present invention. 

[0035] As shown in Figure 2. the financial integration 
framework comprises of three main sections 201 , 202, 
and 203. The first section 201 is a set of base classes 
which are used by the particular source of financial 
transactions. The second section 202 is a generic data 
conversion engine which uses the specializations in the 
first section 201 as their abstract base classes to map 
from the particular source's particular items of interest 
to associated items in the interface of the General 
Ledger The third section 203 consists of the interface to 
the General Ledger (GL) which allows information to be 
generically passed to the General Ledger and hide the 
particular implementation or if It is even preset. 
[0036] A business application component that wishes 
to use the financial integration framework must first 
define a set of concrete classes which are subclassed 
from base classes provided by the framework. The func- 
tion of these concrete classes is primarily derived from 
the framework base classes. The domain-spedf ic con- 
crete classes provide additional isolation between the 
.business application component and the framework and 
allow the component developer to define a domain-spe- 
cific interface that is meaningful to the remainder of the 
component. This greatly improves ease of use of the 
framework during application development. 
[0037] In an embodiment of the invention, the follow- 
ing base classes defined by the framework must be sub- 
classed by the business application component 
developer: 



AccountControlType: 

[0038] The AccountControlType base class allows the 
framework to use any domain-specific class in the 

5 generic data conversion engine. The application com- 
ponent developer must define a subclass of this class 
for each domain-specific class to be used by the engine. 
An instance of each of the component-defined sub- 
classes is then given to the generic data conversion 

10 engine. The engine maintains the order of this set and 
uses it during the generic mapping process. 

DomainGenericlntegrationKey: 

15 [0039] The application component developer creates 
a single subclass of the DomainGenericlntegrationKey 
base class. This subclass converts the generic Integra- 
tion Key interface into one which conforms to domain- 
specific terminology, e.g., setProduct, setWarehouse. 

20 Each domain-specific interface on the subclass is cou- 
pled to one or more domain-specific AccountCon- 
trolType subclasses. 

The AccountControlType subclass serves as an index 
when building the GenericKey used by the generic map- 
25 ping process. 

GenericGLDissectionCreateTemplate: 

[0040] Subclasses of the GenericGLDissectionCrea- 
30 teTemplate class are used to encapsulate all the infor- 
mation needed by the financial integration framework to 
create 

a GenericDissection. Each template subclass is associ- 
ated with a DomainGenericDissectionType instance, 

35 which is used by the generic data conversion engine to 
select the proper mapping subset when processing the 
template. Each template subclass allows the application 
component developer to pass all the necessary domain- 
specific information that is required for the dissection 

40 when an instance of the subclass is instantiated. The 
subclass then packages this information into a form 
which is compatible with the generic data conversion 
engine. Part of this processing includes building an Inte- 
gration Key using the domain-specific subclass 

45 described earlier. 

[0041 ] The business application component must also 
create one or more instances of the DomainGenericDis- 
sectionType class, associating each instance with one 
or more AccountControlType subclasses. TTiis associa- 

50 tion defines the domain-specific classes that are of 
interest of 

a particular dissection type. One instance of the 
DomainGenericDissectionType class is created for 
each GenericGLDissectionCreateTemplate subclass 
55 defined by the business application component. 

[0042] The financial integration framework further 
includes a set of base classes which support the inter- 
faces used by the generic data conversion engine. This 
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allows the financial integration framework to operate in 
the absence of 

a General Ledger application component. The base 
classes provided by the framework include: 

GenericGUournal 

[0043] This class represents a set of dissections 
which are to be posted concurrently to the General 
Ledger (GL). Typically for a journal to be posted suc- 
cessfully, the sum of its debit dissections must equal the 
sum of its credit dissections. 

GenericDissection 

[0044] This class represents a specific financial entry 
(either debit or credit) which is to be posted to the Gen- 
eral ledger as part of a journal. It contains 
a GenericPostingCombination along with quantity and 
value information. 

GenericPostingCombination 

[0045] This class identifies the General Ledger 
account that 

a dissection is to be posted to. It is composed of one or 
more GenericAnalysisCodes. 

GenericAnalysisGroup 

[0046] This class represents a group of similar busi- 
ness entities, e.g., department, job function, cost center, 
which are of interest to the user of a General ledger 
application. Each instance of a group is represented by 
a GenericAnalysisCode. 

GenericAnalysisGode 

[0047] This class represents a specific business entity 
within a GenericAnalysisGroup. Instances of this class 
are defined by the user. During setup of the finanacial 
integration framework, the user associates a GenericA- 
nalysisCode instance with a set of domain-specific 
object instances. These domain-specific object 
instances are selected from the AccountControlTypes 
specified by the user as meaningful for the combination 
of DomainGenericDissectionType and GenericAnaly- 
sisGroup. These mapping pairs form the core of the 
information which is used by the financial integration 
framework to process financial transactions. 
[0048] While the financial integration framework oper- 
ates in the absence of a General Ledger application 
component, such a component must be provided by the 
application in order for any meaningful financial 
processing to be completed. A General Ledger compo- 
nent is easily integrated into the framework by simply 
configuring the framework's object factory to replace the 
generic versions of the classes listed above with 



replacement classes provided by the General Ledger 
component. Other components using the financial inte- 
gration framework - and indeed, the framework itself - 
are not aware of this class replacement, as ail the func- 
5 tion needed to complete their portion of the financial 
integration task is defined at the generic base class 
level. 

[0049] Legacy non-object-oriented General Ledger 
applications can be easily integrated into this framework 

10 in the same way. The sutxilasses used for such integra- 
tion are defined to map between the generic object-ori- 
ented framework interfaces and the procedural 
interfaces provided by the legacy application. 
[0050] The generic data conversion engine defined by 

15 this invention provides, at its core, a generic mapping 
process which is capable of mapping between 
instances of domain-specific classes defined by the 
using components of the framework and instances of 
the General Ledger specific base classes defined by the 

20 framework. This mapping mechanism provides sepa- 
rate instances for each using component, so that each 
component has the freedom to independently define its 
mapping rules without danger of interference from the 
other components of the application, allows any number 

25 of Dissection types to be defined genericaily by the 
using component, each of which can be associated with 
any number of domain-specific classes to be used by 
the mapping engine, and allows the application user to 
selectively enable the use of any or all of the domain- 

30 specific classes defined by the using component by 
coupling those classes to Generic Analysis Group class 
instances previously defined by the user and associat- 
ing specific combinations of domain-specific class 
instances to Generic Analysis Code class instances 

35 defined by the user for each Generic Analysis Group. 
[0051] The engine also provides a generic journal 
building process which bundles the generic transactions 
supplied by the application component into a consoli- 
dated form compatible with the General Ledger applica- 

40 tion component associated with the financial integration 
framework. 

[0052] The generic mapping process must be capable 
of working with domain-specific classes without explicit 
knowledge of their type or contents. Such knowledge 

45 must be avoided because otherwise the framework 
would be unacceptably coupled to a specific domain 
implementation and extension of the framework to new 
domain areas would become cumbersome. 
[0053] This is a primary problem of the framework, 

50 which this invention provides a solution for. An Access- 
Key/Keyables mechanism defined by frameworks of the 
present invention allows the financial integration frame- 
work to work with any domain-specific class genericaily 
(For Access Key see related patent application "Access 

55 Key Objects", filed with the European Patent Office, 
Application No. 97100566.6, filing date January 16, 
1997). Each domain-specific class of interest to an 
application component is assigned an ID, held generi- 
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cally as a subclass of the framework class AccountCon- 
trolType, known to the financial integration framework 
and a position within the Generic Key used by the map- 
ping engine. When a domain-defined Dissection is proc- 
essed by the framework, each domain-specific class 
instance is wrapped by a Generic Keyable and placed 
into the previously specified position within the Generic 
Key, This key can then be used during the mapping 
process for the Dissection. Once contained in this man- 
ner, the domain-specific mapping data can be manipu- 
lated generically during the search for the user- 
specified set of Analysis Codes that will make up the 
Posting Combination for this Dissection. 
[0054] Each dissection type defined by a using appli- 
cation component specifies the set of domain-specific 
Attributes via a list of AccountControlType subclass 
instances which can be used by the generic mapping 
process. During application configuration, the user of 
the application must indicate which of the available 
Attribute types will be used in the mapping process and 
the specific mappings which are valid for this installa- 
tion. 

[0055] As shown in Figure 3, mappings may be 
defined for a dissection type 312 and AnalysisGroup 
311, i.e. a specialized mapping 301, or solely for an 
AnalysisGroup 311, i.e. a default mapping 302 which 
applies to all dissection types in the absence of a suc- 
cessful comparison to a dissection type/AnalysisGroup- 
specific mapping. Each of the specific mappings speci- 
fied by the user are encapsulated into AccessKeys, just 
as the input from the domain-specific dissections will be 
during normal operation of the application. Thus, once 
the framework is configured in this way, the conversion 
process is automatic and can be carried out generically 
within the framework by comparing GenericKey 
instances. 

[0056] As shown in Figure 4, the generic mapping 
process is part of the generic journal building process 
supported by the conversion engine. Neither the map- 
ping nor the conversion process is completed at the 
time the domain -specific application component creates 
a dissection template instance 401. Instead, these 
instances are collected and held by the financial inte- 
gration framework until the application initiates the 
generic journal building process 402. The first step of 
this process involves selecting a subset of dissection 
templates based on a configurable policy, for example 
based on a specific JournalCreationId provided by the 
application component when it created the dissection 
template. Each template in the set is then processed, 
first by completing the generic mapping which results in 
the creation of 

a GenericPostingCombination, followed by building 
a GenericDissection from the GenericPostingCombina- 
tion and the remaining information held by the template. 
Once the GenericDissection is built, it can be inserted 
into the GenericJournal 403 created for this subset of 
dissection templates. After all the dissection templates 



have been processed in this way, the GenericJournal is 
posted and financial integration processing is complete. 
[0057] Figure 5 shows an example of mapping for one 
Analysis Group for a particular Generic Dissection Typje. 

5 In this case the Generic Dissection Type is STOCK 
VALUE 501. which is used to indicate to the financial 
portion of the application a change in the value of the 
stock on hand. The target financial application repre- 
sents its accounts in pieces. Each piece is called an 

10 Analysis Group and represents some aspect of interest 
to the user. A typical Analysis Group would be Depart- 
ment 502. Within an Analysis Group the specific values 
are called Analysis Codes 503. For example the Analy- 
sis Group Department might contain Analysis Codes 

15 like SALES, ENGINEERING, etc. Thus, an account is 
made up of a set of Analysis Codes each for an Analysis 
Group. 

[0058] In this particular example only Analysis Group 
2 - Department 502 is shown. For Analysis Group 2 only 

20 the Account Control type for Warehouse 506 is used. 
Figure 5 shows that warehouse "BB001" 507 maps to 
Analysis Code "BB" 504. Thus, when using the Stock 
type Generic Dissection type, given "BB001" for the 
warehouse Account Control type will result in the "BB" 

25 Analysis Code being used for Analysis Group 2. 

[0059] Figure 6 shows a more complex example with 
two Generic Dissection types (Stock Adjustment 607 
and Stock Value 608), three Analysis Groups (1 = Main 
Account 609, 2 = Department 610, and 3 = Product 

30 611), and three Account Control types (Product 612, 
Warehouse 613, and Cost Type 614). Map 601 shows a 
special case where a particular Analysis Code should 
be used for the Analysis Group no matter what Account 
Control type is used. In this particular case, Analysis 

35 Code "4550" will always be used. Maps 602. 603, and 
605 are similar to Figure 5 described above. Map 606 is 
used to show that all possible Analysis Groups do not 
have to be used and in 606 no Analysis Code is desira- 
ble for Analysis Group 3 (not used) for this particular 

40 Generic Dissection type. Map 604 shows a case where 
more than one Account Control type is used. In this par- 
ticular case Cost Type 614 and Product 612 are used. 
Thus for a cost type of "CNS01 "(normal) 615 and a 
product of "BFTROr(trike) 616 the Analysis Code 

45 "1512" 617 would be used. 

[0060] Figure 7 shows an example of using the maps 
defined in Figure 6. In this example the specified 
Account Control type values are used for each of the 
Generic Dissection types to determine the appropriate 

50 Analysis Codes to build the Account for giving the infor- 
mation to the financial application. 

Claims 

55 1. A framework to be used for developing a software 
system, e.g. for a business application, 
said framework is a financial integration framework, 
characterised in that said financial integration 
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framework comprises 

using non-financial component integration 
base classes, 

target financial component integration base 5 
classes, and 

a generic data conversion engine. 
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2. The framework according to claim 1 , wherein 

a set of conaete classes are defined by said 
business application, said concrete classes are 
subclassed from said using non-financial com- 
ponent Integration base classes provided by 
said framework. is 

3. The framework according to claim 2, wherein 

function of said concrete classes is primarily 
derived from said base classes. 20 

4. The framework according to one of claims 1 to 3, 
wherein 

said target financial component integration 25 
base classes support interfaces used by said 
generic data conversion engine. 

5. The framework according to one of claims 1 to 4. 
wherein 30 

said generic data conversion engine provides a 
generic mapping process which is capable of 
mapping between instances of domain-specific 
classes defined by said using components and 35 
instances of said financial specific base 
classes. 

6. The framework according to one of claims 1 to 5, 
wherein 40 

said target financial component integration 
base class support interfaces are used in con- 
junction with said generic data conversion 
engine to generate entries into said target 45 
financial component. 

7. A method of developing a software system using an 
Object Oriented Technology and a framework, 

said framework is according to one of claims 1 to 6. so 

8. A data storage medium characterised in that said 
data storage medium is storing a framework. 

said framework is according to one of claims 1 to 6. 

55 
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INPUT ACCOUNT CONTROL TYPE VALUES 
COST TYPE PRODUCT WAREHOUSE 



NORMAL MOUNTAIN BIKE ROCHESTER 

CNS01 BFMB01 RCH001 



RESULTING ANALYSIS CODES 
STOCK ADJ. DISSECTION: 

AG 1 = 4550. AG2 = RCH. AG3 = 100 
STOCK VALUE DISSECTION: 

AG 1 = 1510, AG2 = RCH 



9 



EP0 897149 A1 



SET OF CLASSES USED BY 
PARTICULAR SOURCE OF FINANCIAL 
TRANSACTIONS 201 



- SPECIALIZED 
AccountControlType 
DomainGenericlntegrationKey 
GenericGLDissectionCreateTemplate 

-AS IS 

DomalnGenericDissectlonType 



GENERIC MAPPING FACILITY 202 



GENERIC DATA CONVERSION ENGINE 




GenericGLJoumal 
Generic Dissection 
GenericAnalysisGroup 
GenericAnalysisCode 



INTERFACE TO GENERAL 
LEDGER (GL) 203 




Fig. 2 
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Analysis Group Dissection Type 
311 312 



301 



Integration Key Analysis Code 



Analysis Group 
311 



302 



Integration Key Analysis Code 



Fig. 3 



APPLICATION CREATES 401 
TEMPLATES FOR DISSECTIONS / 
(DISSECTION TEMPLATES) ^ 
AND ADDS THEM TO A QUEUE 



DISSECTION TEMPLATES ARE 
CONVERTED INTO DISSECTIONS 
AND COLLECTED INTO JOURNALS 



Y 



402 



GENERAL LEDGER JOURNALS EXIST |/~ 

A) VALIDATE 

B) POST TO GENERAL LEDGER 



403 



Fig. 4 
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GENERIC DISSECTION TYPE: STOCK VALUE 501 (WHS_STOCK_VALUE) 



ANALYSIS GROUP 2 - DEPARTMENT 502 
ACCOUNT CONTROL TYPE{S) 



WAREHOUSE 506 

BB001 (BOEBLINGEN) 507 
RC001 (ROCHESTER) 



ANALYSIS 503 
CODE DESCRIPTION 
BB 504 BOEBLINGEN 
RC ROCHESTER 



Fig. 5 



GENERIC DISSECTION TYPE 
STOCK ADJUSTMENT ^ 

601 



ANALYSIS GROUP 1 - MAIN ACCOUNT 



ACT 



607 



609 



AC DESCRIPTION 



614 



FIXED ACC. USED 4550 STOCK ADJ. 



615 



616 



602 /— 610 

ANALYSIS GROUP 2 - DEPARTMENT 



ACT (WAREHOUSE) AC 
613 

BB001 (BOEBL.) BB 
RC001 (ROCH.) RCH 



DESCRIPTION 

BOEBLINGEN 
ROCHESTER 



603 

ANALYSIS GROUP 3 - PRODUCT 



611 



ACT (PRODUCT) 
\— 612 
BFMB01 
BFRB01 
BFTR01 



AC DESCRIPTION 

100 MOUNTAIN BIKE 

200 RACING BIKE 

300 TRIKE 



GENERIC DISSECTION TYPE 
STOCK VALUE ^ 

608 

604 y- 609 

ANALYSIS GROUP 1 - MAIN ACCOUNT 

ACT AC DESCRIPTION 

(COST TYPE; PRODUCT) 
^ \- 612 

CNS01 (NORMAL) STK VALUE 
BFMB01 1 51 0 MOUNTAIN BIKE 
BFRB01 1511 RACING BIKE 
^ BFTR01 1512 v JRIKE 
CDS01 (DAMAGED) 
BFM801 1550 DAMAGED 
BFRB01 1550 DAMAGED 
BFTR01 1550 DAMAGED 

y— 605 X— 610 

ANALYSIS GROUP 2 - DEPARTMENT 

ACT {\A/HS) AC DESCRIPTION 
\- 613 

BB001 (BOEBL.) BB BOEBLINGEN 
RC001 (ROCH.) RCH ROCHESTER 

y- 606 
ANALYSIS GROUP 3 - NOT USED 



Fig. 6 
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